A software complex is a group of one or more software members that share information and that have operations that act on that information. Generally, in order to develop a software complex, whether it be for a single user on a local computer or a multi-tier, multi-component, multi-user, multi-platform client environment software system, a team of developers and other information technology (IT) professionals must specify, design, build, test, and commission the software complex.
At a high level, a software complex is developed through a three-step process of design, develop, and produce, expressed as Input→Build→Output. In this expression, the “input” is the collection of all design specifications, requirement specifications, research, analysis, decisions, experiences, techniques, knowledge, know-how, ideas, and expertise of the development team(s) and other subject matter experts for producing a unique output. The “build” is the effort exerted by the development team(s) to process the information and write(s) the actual code that becomes the deliverable for the software complex. Thus, the “build” represents a group of people that take the “input,” process it, and incur the effort required to build the “output.” The “output” is the desired software complex.
Generally, to truly satisfy a particular input so that a particular output is produced, there is an unstructured collection of implicit and explicit decisions, experiences, techniques, knowledge, written documents, and ideas. The whole input does not exist in any tangible form as some of the information exists in the minds of the team members and subject matter experts. In fact, even explicit input parameters may be interpreted differently among different team members, depending on their experience and knowledge. Consider, for example, a software complex that manages lists of people's names as part of its functionality. One input to such a system may be “all last names shall have a maximum length of 25 characters.” This is straightforward input and is not easily misunderstood. However, an input requirement like “the list shall be sortable” is open to many technical interpretations, such as “sorted by last name,” “sorted by first name,” “sorted by both first name and last name,” “sorted alphabetically ascending,” or “sorted alphabetically descending.”
In traditional software development, many of the key aspects of the “input” are inadvertently handled completely independently of one another. Some of the aspects are answered explicitly with an extensive definition. Other aspects are never addressed directly, resulting in implicit decisions being improvised during the course of the software development. While some aspects are documented, others precipitate based on the experience and preferences of the development team. There are often numerous interdependencies between aspects of the “input.” Without a mechanism to manage the complexity of the interdependencies, logical collisions do occur and can ripple through a project causing less than desirable results, inefficiencies, and higher software development costs.
Another problem with traditional software development is that individual components of a software complex are typically built by different individuals, if not by completely different groups, divisions, subcontractors, or companies. In such cases, the subset of design aspects pertaining to a particular component may be managed completely separately from the whole of the software complex. Some IT professionals believe that components of a software complex can be cleanly separated and distributed to different IT professionals (e.g., different development teams) for completion. The loss of integrity between the whole and the parts makes it very difficult to produce a sophisticated software complex successfully. Consequently, many software systems are built today in a very craftsman-like manner.